Protože počet nástrojů je vysoký a jejich technický popis je snadno dosažitelný, budeme se v tomto článku věnovat především důležitým atributům, podle kterých je vhodné nástroj vybírat.

Podpora aplikace

Při výkonnostních testech je simulována činnost reálných uživatelů pracujících s danou aplikací. Nástroj ovšem fyzicky nepracuje s klientským programem, tak jako reálný uživatel. Pomocí příslušného protokolu pouze simuluje komunikaci, která probíhá mezi klientskou a serverovou částí aplikace při provádění vybraných uživatelských činností. Toto řešení přináší jednu z největších výhod automatizovaného výkonnostního testování, a sice možnost simulovat stovky současně pracujících uživatelů z jednoho počítače. Z popsaného principu však zároveň vyplývá, že schopnost nástroje testovat určitý typ aplikace závisí především na implementaci odpovídajícího komunikačního protokolu.
Největší podporu mezi nástroji mají dnes klasické webové aplikace a web services, založené na protokolu HTTP. Díky jejich velkému rozšíření a relativně jednoduchému protokolu je umožňuje testovat i řada volně šiřitelných nástrojů. Freewarové nástroje jsou však většinou úzce specializované na konkrétní typ aplikace a nepodporují řadu dalších technologií používaných v podnikové a komerční sféře. Požadavky větších organizací na všestrannost nástroje tedy obvykle nepokryjí.
Univerzálnější řešení nabízejí komerční nástroje. Jedná se zpravidla o robustní aplikace, které umožňují testovat velké množství rozmanitých technologií. Kromě výše zmíněných jsou to zejména:

• moderní webové a multimediální aplikace (Ajax, Flex, Real, Media Player, ...),
• dvouvrstvé aplikace (Oracle, Sybase, Informix, MSSQL, ODBC, ...),
• CRM a ERP systémy (SAP, Siebel, Peoplesoft, ...),
• centralizační technologie a terminálové aplikace (Citrix, RDP, ...),
• aplikace postavené na technologiích Java a .NET.

Seznam konkrétních protokolů se u jednotlivých nástrojů liší stejně jako úroveň jejich podpory. Výrobci komerčních nástrojů obvykle umožňují zákazníkům z nabídky vybrat a zakoupit pouze ty protokoly nebo skupiny protokolů, které odpovídají jimi používaným technologiím.
Prvním krokem při výběru nástroje by tedy mělo být definování všech aplikací, respektive komunikačních protokolů, které s daným nástrojem zamýšlíme testovat, a následné ověření úrovně jejich podpory. I v případě, že nástroj vybíráme pro jeden konkrétní typ aplikace, měli bychom prověřit možnosti jeho budoucího rozšíření.

Možnosti simulace reálné zátěže

Pokud požadujeme, aby byl výsledek výkonnostního testu vypovídající, nestačí pouze „zahrnout“ testovaný systém velkým množstvím dotazů. Při reálném provozu systému se vyskytuje řada faktorů, které mohou výkonnost a chování systému významně ovlivnit. Uživatelé se do aplikace připojují v různých časech pomocí různých klientských programů s rozdílným nastavením, zadávají rozmanitá data, pracují rozdílnou rychlostí. Abychom mohli tyto reálné faktory v testu zohlednit, musí nám k tomu nástroj nabídnout příslušné prostředky. Jedná se především o:

• funkce pro parametrizaci uživatelských dat (unikátní položky pro každého uživatele, náhodný výběr ze seznamu hodnot, ...),
• možnosti „reakce“ virtuálního uživatele na odpověď serveru (náhodný výběr řádku v zobrazené tabulce, použití nalezeného řetězce v odpovědi, rozhodovací logika pro výběr dalšího kroku uživatele, ...),
• možnost vytvoření uživatelských skupin a přiřazení příslušných uživatelských profilů (rychlost a rytmus práce, vlastnosti síťového připojení, typ a nastavení klientské aplikace, ...),
• libovolné nastavení rozložení zátěže v čase (postupné odhlašování/přihlašování virtuálních uživatelů a uživatelských skupin, možnost vytvoření náběhových vln, ...).

Efektivita práce s nástrojem

Nízký „uživatelský komfort“ při práci s nástrojem znamená vždy nárůst pracnosti a tím i zvýšení nákladů na provedení testu. Levnější nástroje často bývají z tohoto hlediska hůře vybaveny, což musí být vyváženo vyšší pracností při přípravě a realizaci. Efektivitu práce s nástrojem je jistě nutné ověřovat v celém rozsahu jeho funkcionality, my se ovšem zaměříme na nejbolestivější místo, kterým je vytváření zátěžových skriptů. Tato činnost představuje obvykle časově nejnáročnější část práce s nástrojem a nezřídka bývá také nejnáročnější fází přípravy výkonnostního testu. Největší úspory lze tedy dosáhnout především zde.
Dnešní technologie nabízejí řadu funkcí pro automatické generování, úpravy a odladění programového kódu. Tyto funkce se s úspěchem používají i u moderních testovacích nástrojů pro zefektivnění práce při přípravě testovacích skriptů. Patří mezi ně zejména:

• automatické generování skriptu ze záznamu činnosti reálného uživatele (nahrávání skriptů),
• vizuální editace skriptů nad GUI prvky aplikace,
• automatické vyhledávání a parametrizace dynamicky generovaných hodnot,
• snímání obrazovek aplikace při přehrávání skriptu s možností porovnání se snapshoty získanými při nahrávání.

Tato funkcionalita přináší úspory při provádění časově náročných rutinních operací a zároveň zpřístupňuje vytváření skriptů uživatelům bez hlubších znalostí programování a podrobných technických principů komunikačních protokolů. Vizuální metody úpravy skriptů mají však vždy svá omezení. Velkou výhodou tedy je, pokud nástroj umožňuje také přímo editovat zdrojový kód skriptu. V případě, že je tento kód založen na některém ze standardních programovacích nebo skriptovacích jazyků (C, Java, JavaScript, VBScript apod.), získáváme navíc možnost použití řady funkcí a volně dostupných knihoven. Ty lze využít zejména při, z pohledu nástroje, nestandardním chování aplikace nebo při specifických požadavcích na funkcionalitu skriptu.
Při ověřování možností nástroje je třeba mít na paměti, že každý komunikační protokol má svá specifika, a proto se obtížnost vytváření skriptů pro různé druhy aplikací může i v rámci jednoho nástroje podstatně lišit.

Úprava skriptu v nástroji HP LoadRunner

Monitoring

Aby bylo možné lokalizovat příčinu problémů, je nutné při testu sledovat množství výkonnostních metrik na různých vrstvách a prvcích systému (webové, aplikační, databázové servery, síťové prvky apod.). Tyto metriky a způsob jejich získávání jsou většinou specifické pro konkrétní hardwarový či softwarový produkt, a často se liší dokonce i mezi jeho jednotlivými verzemi. Důležitou vlastností testovacího nástroje je tedy i výčet produktů a parametrů, které je schopen monitorovat. Obdobně jako u protokolů bychom se i zde měli zaměřit především na technologie, které v současnosti používáme v naší organizaci, ale zároveň bychom neměli zapomínat na budoucnost. Za ověření stojí zejména schopnost výrobce reagovat na technologický vývoj a pravidelně zařazovat podporu monitoringu pro nejnovější verze daných hardwarových a softwarových produktů.
Nedostatečná podpora monitoringu ze strany nástroje znamená vždy buď snížení vypovídací hodnoty výkonnostních testů, nebo navýšení jejich pracnosti. Každý prvek systému, který není možné sledovat pomocí testovacího nástroje, je nutné monitorovat alternativním způsobem. To obvykle zvyšuje požadavky na součinnost ostatních odborných rolí (síťový administrátor, správce app. serveru, databázový administrátor apod.). Další pracnost je pak generována ještě ve fázi vyhodnocení testu, kdy je nutné získaná data upravit do jednotného formátu a vyhodnotit v kontextu s průběhem generované zátěže

Vyhodnocení výsledků testu

Způsob vyhodnocení výkonnostních testů, který jsme popisovali v předchozím díle našeho seriálu, klade na testovací nástroj dva zdánlivě protichůdné požadavky. Jsou jimi přehlednost a současně velká obsáhlost vyhodnocení.
V první fázi vyhodnocení je nutné získat přehled o nejdůležitějších výsledcích testu. Nástroj by tedy měl nabízet stručný a přehledný report obsahující především seznam měřených transakcí se základním statistickým zhodnocením naměřených odezev (průměrná, minimální, maximální hodnota, 50./90. percentil). Součástí reportu by také měly být základní informace o testu a generované zátěži, jako jsou délka testu, čas jeho spuštění a ukončení a maximální počet virtuálních uživatelů.
Při následném „odhalování úzkých míst“ systému je třeba proniknout do větší hloubky. Velkou roli zde hraje dobré grafické zpracování výsledků testu. Důkladná analýza grafů a křivek znázorňujících vývoj hodnot jednotlivých měřených parametrů je totiž prakticky jediná metoda, kterou lze z tak velkého množství dat získat informace o vlivu zátěže na systém. Samozřejmostí by měla být možnost zobrazení detailu jednotlivých křivek pro zvolený časový úsek testu a možnost sloučení křivek z různých měření do jednoho grafu.
Pro zobrazení výsledků testu je obvykle zapotřebí speciálního modulu testovacího nástroje. Je tedy velkou výhodou, pokud lze upravenou sestavu reportů a grafů jednoduše vyexportovat do dokumentu v některém z obecně rozšířených formátů (např. HTML, PDF). Tímto způsobem pak lze například rozeslat podrobné informace o výsledcích testů jednotlivým členům realizačního týmu.

Cena nástroje

Náklady na pořízení nástroje hrají obvykle při jeho výběru rozhodující roli. Licence propracovaných komerčních nástrojů představují investici v řádu statisíců nebo i milionů korun. Takovou sumu peněz řada organizací není ochotna do testovacího nástroje vložit. Z tohoto důvodu často volí levnější nebo freewarové nástroje.
I když obecně nelze říci, že použití těchto nástrojů musí nutně znamenat špatnou volbu, mělo by být toto rozhodnutí vždy řádně uváženo. Freewarové nástroje nelze s ohledem na jejich možnosti a kvality s „drahými“ komerčními nástroji srovnávat. Hrozí zde riziko, že zvýšená pracnost přípravy a realizace testu, řešení technických problémů a kompromisy v kvalitě realizované zátěže převýší původně ušetřené náklady, případně způsobí neúspěch zátěžového testu ve smyslu nenalezení existujícího úzkého místa.
Protože většina projektů testovací nástroj nemůže zaplatit ze svého rozpočtu, je výhodné vytvořit v podnicích s častou potřebou výkonnostních testů sdílené testovací prostředí pro jejich realizaci.

Závěrem

Tento článek uzavírá cyklus o výkonnostních testech. V této sérii jsme se pokusili zdůraznit řešení těch nejdůležitějších problémů jejich realizace a doufáme, že se nám podařilo osvětlit alespoň základní principy problematiky výkonnostního testování. Na závěr bychom vám chtěli poděkovat za pozornost a popřát hodně úspěchů při realizaci výkonnostních testů.

Autoři článku působí ve společnosti Cleverlance Enterprise Solutions. Jiří Sýkora jako test manager, Tomáš Síbrt jako test engineer.